71장. 백업 · 복구 · 재해 복구 전략
이 장에서 말하고자 하는 것
운영 데이터는 다음 시나리오에 대비해야 한다.
- 사람이 실수로 지웠다
- 애플리케이션 버그로 잘못 썼다
- DB 인스턴스가 망가졌다
- 한 AZ 전체가 죽었다
- 한 리전 전체가 죽었다
- 랜섬웨어 / 악의적 삭제
각 시나리오마다 필요한 도구가 다르다.
이 장은 AWS의 백업 · 복구 옵션을 한 줄로 잡는다.
1. 두 가지 핵심 지표 — RTO와 RPO
RTO (Recovery Time Objective) : 얼마나 빨리 복구할 수 있는가
RPO (Recovery Point Objective): 얼마나 옛 데이터까지 잃어도 되는가
RTO 1시간 / RPO 5분
→ 1시간 안에 복구
→ 최근 5분 이내 데이터 손실 허용
이 두 숫자가 백업 · DR 설계의 출발점이다.
더 짧을수록 비용이 폭증한다
2. AWS의 백업 도구
| 도구 | 무엇을 백업 | 특징 |
|---|---|---|
| RDS 자동 백업 | RDS · Aurora | 매일 + 트랜잭션 로그 → PITR |
| RDS 수동 스냅샷 | RDS · Aurora | 사람이 명시적으로, 영구 보관 |
| DynamoDB PITR | DynamoDB | 35일간 어느 시점이든 복구 |
| DynamoDB 백업 | DynamoDB | 사람이 명시적으로 |
| S3 버전 관리 | S3 | 객체 변경/삭제 이력 |
| EBS 스냅샷 | EBS | 디스크 시점 백업 |
| AWS Backup | 위 전부 + EFS + 더 | 통합 백업 관리 |
통합 운영에는 AWS Backup 이 핵심이다
3. Point-in-Time Recovery (PITR)
가장 강력한 회복 도구.
RDS · Aurora · DynamoDB:
지난 N일(보통 35일) 동안의 어느 시점으로도 복구 가능
예:
2026-03-15 14:23:11 직전 상태로 복구
사람이 실수로 데이터를 지운 시각 직전으로 정확히 돌아갈 수 있다.
운영 DB의 PITR은 사실상 필수
4. 시나리오별 도구
시나리오 1. 사람이 실수로 한 행 삭제 (30분 전)
→ PITR로 30분 전 시점 복구
시나리오 2. 한 테이블이 망가짐
→ 백업/스냅샷에서 그 테이블만 복원
시나리오 3. DB 인스턴스 자체 장애
→ Multi-AZ Standby로 자동 페일오버
시나리오 4. AZ 전체 장애
→ Multi-AZ 가 처리
시나리오 5. 리전 전체 장애
→ Cross-Region Replica / Backup → 다른 리전에서 복구
시나리오 6. 악의적 광범위 삭제
→ 별도 AWS 계정에 백업 복제 (vault lock) 필요
5. AWS Backup — 한 곳에서 관리
Backup Plan
├─ 일정: 매일 새벽 3시
├─ 보관 기간: 30일
├─ 대상: RDS · DynamoDB · EFS · EBS
└─ 다른 계정/리전으로 복사 (선택)
- 각 서비스의 백업 설정을 따로 관리하지 않아도 된다
- 보관 기간 · 암호화 · 복제 정책을 일관되게 적용
5개 이상의 다양한 자원을 백업한다면 AWS Backup으로 통합
6. Vault Lock — 백업 자체를 지키기
악의적 사용자가 운영자 권한을 탈취해 백업까지 지우는 시나리오가 있다.
AWS Backup은 Vault Lock 을 제공한다.
Vault Lock 활성화 → 보관 기간 내 백업은 누구도 못 지움
규제 산업 · 중요한 데이터에는 거의 필수.
7. Cross-Region DR
리전 전체 장애를 대비하려면 다른 리전에 백업 또는 복제 필요.
RDS / Aurora → Cross-Region Read Replica 또는 백업 복사
DynamoDB → Global Tables
S3 → Cross-Region Replication
AWS Backup → Copy to another region
리전 DR은 비용이 큰 결정 — 정말 RTO/RPO 요구가 강할 때만
8. 우리 서비스에서
[AWS Backup Plan: daily-prod]
대상: 모든 운영 RDS · DynamoDB · EFS
일정: 매일 새벽 3시
보관: 30일
교차 리전 복사: us-east-1 (선택)
[RDS]
자동 백업 7일, PITR 가능, Multi-AZ
[DynamoDB]
PITR ON
[S3 운영 버킷]
버전 관리 ON, 만료 후 옛 버전 정리
대부분의 실수 / 장애가 이 구성으로 회복 가능하다.
9. 직접 확인해보기 — CLI
RDS PITR로 복원
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier orders \
--target-db-instance-identifier orders-restored \
--restore-time 2026-03-15T14:23:11Z
DynamoDB PITR 켜기
aws dynamodb update-continuous-backups \
--table-name orders \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
AWS Backup Plan 보기
aws backup list-backup-plans
aws backup list-backup-jobs --by-state COMPLETED
10. 코드로는 이렇게 생겼다 — Terraform
resource "aws_backup_vault" "main" {
name = "main-vault"
}
resource "aws_backup_plan" "daily" {
name = "daily"
rule {
rule_name = "daily-3am"
target_vault_name = aws_backup_vault.main.name
schedule = "cron(0 18 * * ? *)" # UTC 18 = KST 03
lifecycle {
delete_after = 30
}
copy_action {
destination_vault_arn = aws_backup_vault.dr.arn # us-east-1
}
}
}
resource "aws_backup_selection" "prod" {
name = "prod-resources"
plan_id = aws_backup_plan.daily.id
iam_role_arn = aws_iam_role.backup.arn
resources = [
aws_db_instance.orders.arn,
aws_dynamodb_table.products.arn,
]
}
11. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. 백업만 하고 한 번도 복구를 시도해보지 않는다
“백업 되는 줄 알았던” 데이터가 실제로는 복구 불가능한 경우가 많다.
분기마다 복구를 시뮬레이션 — 실제 다른 환경에서 복원해본다
안티패턴 2. 백업도 같은 계정 · 같은 리전에만 둔다
악의적 계정 탈취에 한 방에 다 사라진다.
별도 백업 계정 또는 별도 리전 복사
안티패턴 3. PITR 기간을 1일로 둔다
사람이 실수를 알아채는 데도 며칠 걸린다.
최소 7일, 운영은 보통 30일
안티패턴 4. RTO/RPO를 정의하지 않은 채 백업한다
실제 사고가 났을 때 “얼마나 빨리?” 가 의사결정의 기준이 없다.
12. 한 줄로 정리
백업 · 복구는 도구 묶음이 아니라 RTO/RPO 기반의 설계이며,
정기적인 복구 시뮬레이션이 진짜 안전망이다
13. 이 장의 핵심 정리
- RTO/RPO 가 백업 · DR 설계의 출발점이다.
- PITR은 사람의 실수에 가장 강력한 도구다.
- Multi-AZ · Cross-Region Replica · AWS Backup이 각자의 자리에 있다.
- AWS Backup으로 여러 자원을 통합 관리한다.
- Vault Lock · 별도 계정 백업으로 악의적 삭제에 대비한다.
- 복구 시뮬레이션 없는 백업은 백업이 아니다.